QRZ! Ham Radio 9/QRZ Ham Radio Callsign Database - Volume 9.iso/pc/files/t_docs/faq_1292.txt

Text File | 1996-06-24 | 77KB | 1,958 lines

NOS FAQ    draft                    15-Dec-92

[This is a draft -- forgive ugliness, and help repair it!]

This paper discusses the TCP/IP implementation known as NOS,
originated by Phil Karn and developed by many others.  It tries not to
duplicate material that is available elsewhere, but refers instead to
existing documentation.  If you have never seen NOS before, you might
want to scan this document quickly, and then go read the "Introduction
to NOS" file by John Ackermann or the "Beginner's Guide to TCP/IP"
(both described later).

If you maintain or use a NOS variant, please check its description
here in this paper.  If it's wrong, or if there isn't one, please tell
the maintainer.  Other additions and corrections are also welcome.

This document is maintained by [e-mail], as of December 1992.

----------------------------------------------------------------------
Repositories

    The best place to get NOS is from someone you know who is already
    using it.

    You can get it over the Internet from several anonymous FTP sites.
    The best-known site is ucsd.edu.

    ucsd.edu:/hamradio/packet/tcpip

        grivel.une.edu.au    (Australian mirror of ucsd.edu)

    [ ucsd needs a README with one-liners for each directory ]

    It is also found on many telephone BBS systems, including:

    N8EMR's Ham BBS        [phone]
    ChowdaNet        [phone]    V.32    (Fidonet 1:323/120)
    ChowdaNet        [phone]    V.32bis
    The Antenna Farm    [phone]    V.32bis N81

    WB3FFV            (301) ?
    Gracilis BBS        ?
        AMNET BBS        [phone] (Australia)

    N1BEE distributes a cleaned-up version of the GRI code.  The
    primary distribution point is ChowdaNet.  This seems to be
    one of the more stable and solid end-user releases, though the
    last version is nearly a year old now.


Documentation

    Unfortanately, NOS is poorly documented compared to many other
    programs.  This is not due to a lack of effort by the developers.
    It is because there are so many versions of NOS, being
    developed by many people who have no regular contact, and each
    version changes very frequently.  Any documentation quickly
    becomes out of date.

    For some features, there is no documentation at all.  Other
    features that are documented aren't present in all executables,
    even those produced by the same source, because that feature may
    have been turned off in the executable you are using.

    Thus, it is likely that the documentation you can find won't
    exactly match the program you are using, and you will have to
    refer to a full "base" manual and to another document that
    describes the differences from the base version.


    intronos.zip  This is the best introduction to NOS for people
          who understand something about packet radio.

    userman.zip      A complete user manual for the last pre-NOS version
          of NET... 890421.1

    nos_1229.man  A complete user manual for PA0GRI NOS.

    help_v02.zip  mailbox help files (for ka9q 901130)

    The several volumes of the ARRL Computer Networking Conference (CNC)
    Proceedings contain many papers on TCP/IP and NOS.  These are
    available from ARRL Headquarters in Newington, CT.

    Send mail to [e-mail] for an automatic response pointing at
    more information about the ARRL.

    Particularly useful CNC articles are listed in the bibliography
    at the end of this document.

    Some of these papers are available online in the directory
    ucsd.edu:/hamradio/packet/tcpip/docs.

    Other papers are also available on ucsd.edu:

    ka9qnos.ps.Z
    netnix-paper.ps.Z
    connex.Z
    1987            Directory of papers from CNC 1987
    1988            Ditto 1988

    There is no document dedicated to describing the internals of NOS.
    There is a section of the user manual that describes some of the
    socket library calls.  Look in the section on NOS Internals here
    in this document.

    John Ackermann, AG9V <[e-mail]> offers:

    I hesitate to make the offer, but on a time-permits basis I
    can provide a hard-copy set of my doc, the PA0GRI ref manual,
    the Rutgers tcp/ip intro, and a disk with N1BEE's GRINOS for
    the cost of copying and mailing -- usually $10 or $15.  It's
    best to call, write, or email first to find out what the
    turnaround time is likely to be.  My mailing address:

        John Ackermann   AG9V
        2371 Stewart Road
        Xenia, OH   45385


    Gary Ford <[e-mail]> has written a "Beginner's Guide
    to TCP/IP on the Amateur Packet Radio Network Using the KA9Q
    Internet Software" alternately titled "End User's Guide to TCP/IP".
    Version 2.0 of the guide documents the use of NOS 911229 (PA0GRI
    v2.0h) and BM v3.3.2.  It is available on:

    ftp.eecs.ucdavis.edu:pub/ka9q
     or ucsd.edu:hamradio/packet/tcpip/docs

    nosbgnlp.zip    unzips to a 66 page ascii "line printer" document,
            which can be printed with the UNIX lpr command.

    nosbgnps.zip    unzips to a 54 page PostScript document, which can
            be printed on a PostScript printer.

    nosbgnpr.zip    unzips to a 66 page ascii "print" document, which
            can be printed using the DOS print command.  You
            will need to send control codes to your printer to
            control the page offset and you should turn
            perforation skip off.  (not on ucsd.edu)


Mailing lists

    rec.radio.amateur.packet    (Usenet newsgroup)

    This is the place to ask beginner questions, such as
    "How can I use a baycom modem with NOS?"

    [e-mail]

    This is a forum for NOS developers to discuss things they're doing.
    It is NOT the right place to ask beginner questions.

    Send mail to [e-mail] with the word HELP as its only contents.
    It will send you instructions by return mail.

    [e-mail]

    The purpose of this list is discussion of the ins and outs of running
    KA9Q NOS as something approximating a full-service BBS, which generally
    boils down to discussion of the care and feeding of the JNOS version of
    NOS, maintained by Johan, WG7J.  Discussion of peripheral issues which are
    likely to be of interest to NOS BBS sysops, such as the convers server,
    NNTP, POP, etc, are also welcome.

    Submissions to the list go to:
    [e-mail]

    Subscription/deletion requests and other administrivia to:
    [e-mail]

    Note that the reply path for list mail is set to go to the list address,
    not the originator.  That's by design - to encourage *public* discussion.
    If you want to send private mail to a nos-bbs contributor, please take
    care to get the address right!

Operating systems and other machines

    NOS has been ported to several operating systems.  Most development
    still happens under DOS.  At some point, all the different platforms
    could have been built from a single set of sources.  Since then,
    they have diverged enough that re-integrating the changes back into
    a common set of sources would take some effort.

    <[e-mail]> writes:

    When the list of targets was really small, in about 1988-9
    maybe, we had a single set of sources that built on various
    targets... the 890421.1 release supported DOS/Borland and a
    variety of Unix variants.  I haven't paid much attention to
    this since then.


    OS/2
    Windows
    Macintosh
    Amiga


Installation and setup tools

    An installation program for some versions of NOS is available.


    The NOS_KIT package explains well the several files used by NOS for
    configuration.
    It is a package for installation of the 901130 versions of KA9Q
    and G1EMM NOS (it includes executables for 901130 G1EMM and KA9Q).
    This "kit" is a reasonable place for a newcomer to get started.

    Written:  Dave Fritsche (wb8zxu)
    E-mail:   [e-mail]
    Version:  910324
    Path:     UCSD.EDU /hamradio/packet/tcpip/install/nos_kit.*

    Dave writes:

    The "kit" should be unpacked and placed onto floppy disks.  It
    all fits on a single 720k or larger disk.  This disk is then
    used as a NOS installation disk (the files can also just be
    stuffed into a subdirectory on a harddisk if you prefer -- but
    put them in a directory close to root (c:\) -- long pathnames
    screw things up).  Once the installation disk is ready (I hand
    them out to locals), just put the disk in a drive, change to
    the drive (e.g: a:), then type "install".  The user is
    presented with two screens of "fill in the blanks" kind of
    data.  Just use the <Enter>, <Tab>, <SHFT><Tab>, <Up-arrow>,
    and <Down-arrow> to move between the entries.  It's pretty
    self-explanatory.  There are a couple of questions that
    weren't very clear, that should be cleaned up.  But it's
    something to help get a person off on the right foot.  After
    the blanks have been filled in, the installer goes off and
    makes all the needed subdirectories, creates an autoexec,
    ftpusers, domain.txt, . . ., and then unpacks the binaries and
    all the support files.

    The "kit_src.*" files, are the source code for the "install"
    program contained in the kit.  Numerous people have recently
    asked me for the source code, so that they could update the
    installation kit for GRI/WG7J NOS.  Sure hope they can pull it
    off!  Wish I had the time to do it myself.  Hopefully, Brian
    will get this source code moved into the "install" directory
    at some time in the near future.  Generally speaking, endusers
    won't need or want these source archives.

Versions

    The main NOS repository harbors a bewildering variety of NOS variants.
    All of them are derived in some way from some ancestor of the
    KA9Q version.  The one that is best for you depends on what you
    want to use it for.

    One reason why there are so many versions of NOS is that it is
    used for widely different purposes by different groups.
    Each one needs it to solve a particular problem, or provide some
    service, so they implement whatever feature they need.  There are
    many such groups throughout the world, and many of them have no
    regular contact with any of the others.

    Each NOS variant tends to reflect the cumulative efforts of a
    person or group, rather than a particular added feature.  Some
    people modify more than one area -- for instance, they might add a
    new TCP server, and "enhance" the way datagrams are routed.

    The variants are usually known by the names of their authors,
    and they often have nicknames.  Some of the more common ones are

    ka9q
    wg7j (jnos)
    pa0gri
    grinos        based on PA0GRI, cleaned up by N1BEE
    pe1chl
    wnos
    hrlnos
    gpsnos        Georgia Packet Switch, produced by GRAPES
            (Georgia Radio Amateur Packet Enthusiasts)
    gracilis
    wampes
    g1emm
    pmnos


    Most versions of NOS share a common core of commands.

    Most versions of NOS have all of the following facilities in them,
    but emphasize one over the others:

        packet switch
        services
        UI terminal

    For example, GPSNOS is optimized to be a standalone packet switch,
    and doesn't offer any other services.  (This is what DOS NOS is
    really best at.) WNOS has a nice split-screen user interface, and
    PMNOS has an even more elaborate one.


    The features supported by NOS can be divided into categories this way:

     network        NETROM, FlexNet
     user-interface        split-window, fkey, command recall
     hardware        special serial ports, network interfaces
     services        callbook server, pop, smtp, convers, mailbox

    Here is a list of the features by category:

    Network

        TCPIP
        AX.25
        NETROM
        WAMPES AX.25 routing    WNOS, WAMPES

    hardware

        asy    standard PC serial port
        hs    high-speed serial driver for 8530 (no DMA)
        scc    generic 8530 driver
        DRSI
        EAGLE
        PI
        PACKTWIN
        dialer

    services

        ttylink (chat)
        mbox
        bbs
        convers
        pop
        smtp
        nntp
        ftp
        finger
        callbook    gracilis

    user-interface

        split-screen (WNOS)
        scrolling, cut/paste, mouse (PMNOS)
        fkey


    ----------------------------------------------------------------------


    These versions have been optimized as packet switches:

          ka9q
          gpsnos
          pe1chl nos
          pa0gri
          gracilis

    These versions emphasize user-interface:

          hrlnos
          minihrl
          wnos
          pmnos

    These versions emphasize services:

          wg7j

    ----------------------------------------------------------------------

    Here are brief descriptions of some NOS variants.  If your
    favorite one isn't here, or if you can describe it better, tell me!
    I'm particularly interested in documenting ancestry where possible.


    net        Phil Karn <[e-mail]>

        The last pre-NOS version of NET... 890421.1
        documentation in userman.zip


    ka9q                                  21-Jun-92
        Phil Karn <[e-mail]>

        This is the base version from which the others are derived.

        [ I haven't tried this one yet. - mg ]

        Latest version on ucsd is 920621.

        wb8zxu:
        A lot of people consider 901130 the last "really good" working version of
        NOS.  After that version, NOS got real fat, and fairly quirky.  It also
        split about 5 different ways . . . PA0GRI, WG7J, PMNOS, WNOS, . . .

    wg7j                                  15-Dec-92
        Johan K. Reinalda   WG7J    <[e-mail]>

        Also called JNOS.

        exchanges mail with W0RLI-style bbs systems
            split-screen ttylink sessions
        command recall (as of 1.07)
        converse
        ip and tcp access control
        accesses all dos drives (not just "root" one)

        This is one of the more actively developing versions.

        Based on KA9Q 911229 release, at least up to JNOS 1.07.
        Later versions will be based on KA9Q 920618.

        This is a service-oriented NOS.  It acts as a "full-service" bbs.
        It can exchange mail with conventional amateur BBS systems,
        such as MSYS and W0RLI, as well as via SMTP and NNTP.

        This version is also widely used as a gateway between
        internet and amateur packet radio networks.

        This has a rewritten 8250 UART driver.
        [I've found it to be slower than the previous one -- see
         later -mg]

        Derived somehow from was0206, pa0gri, wnos.


    pa0gri                                      29-Dec-91
        Gerard van der Grinten, PA0GRI

        This is one of the more actively developing versions.
        This is used as the basis for other versions, including gracilis.

        nos_1229
        gri20m

        mods allowing accessing many disk drives by FTP server
        made for GRINOS 1.8b, draft version for 2.0l and (in
        nearest future) 2.0m available by anonymous FTP on
        zfja-gate.fuw.edu.pl (name GRI20L-1.ZIP).  Jerzy Tarasiuk
        <[e-mail]>

        N1BEE distributes a cleaned-up version of the GRI code;
        this cleaned up version is called GRINOS; it is distinct
        from pa0gri's version.

    grinos
        Mike Bilow N1BEE    <[e-mail]>

        The primary distribution point is ChowdaNet.

        (GRINOS is not a synonym for PA0GRI NOS.)

        This is a cleaned-up and packaged version based on the pa0gri.
        It is one of the more stable and solid end-user
        releases.

        Mike tries to make sure that his bug fixes are recycled
        into the main PA0GRI releases, so you only tend to run a
        version or two ahead on bug fixes with GRINOS.


    gracilis
        [e-mail]
        Don Lemley N4PCR
        Milt Heath

        There seem to be several "gracilis" versions.  One is
        publically available on ucsd.edu.  It seems to be
    derived from pa0gri.

    Gracilis has a special version of NOS that runs in their
    PackeTen -- it doesn't run on a PC.
    The Gracilis PackeTen is a standalone packet switch with a
    special communications processor (the Motorola 68302).
    This standalone version is derived from work described in a
    paper on NOSINABOX by Bdale Garbee, Don Lemley, and Milt Heath
    in the CNC proceedings.

    There are rumors that Gracilis has also substantially
    reworked NOS.  This version doesn't seem to be publically
    available in source form, but they supply it with
    their PackeTwin (and PackeTen) modem/radio hardware.

    [Are the binaries available, and will they support other
     hardware devices?]

    There is a mailing list that discusses Gracilis products.
    To subscribe, send mail to

       [e-mail]

    with an empty subject line and a message body (beginning in
    Column 1) with the command:

           SUBSCRIBE GRACILIS-L _your_address_here_


    Says bdale:

        NOS is integral, and doesn't look a whole lot like NOS
        internally any more.  Don Lemley and Milt Heath at Gracilis
        acquired a commercial text-based window system with source,
        and heavily modified it to work in a mutli-task environment.
        They also found and have integrated an overlay manager to
        deal with the memory size problems.  Don has spent
        considerable time finding and squashing memory leaks, and
        other problems in NOS.  What they ended up with is a
        completely different user interface to a package that does
        all of what NOS does, and more.


    wnos                                 14-Jan-92
        Michael Bentrup (DB3FL)
        Mike Chace (G6DHU @ GB7IMB)

        ucsd.edu:/hamradio/packet/tcpip/wnos

        A very detailed set of manuals for WNOS3 and 4 is in the
        wnos directory on ucsd.edu.

        The author of this software Michael Bentrup (DB3FL).  He
        is sadly not connected to the Internet.  Mike Chace (G6DHU
        @ GB7IMB) produces a version of the software more suited
        to the UK environment where, for example, NET/ROM is
        required.

        WNOS was the first system to port two important features of the
        WAMPES Unix software namely the AX.25 autorouting front-end and
        the convers server. As far as I know, ALL flavours of NOS that
        support the convers server have used the WNOS code and therefore
        should be compatible.

        A unique feature of WNOS is the AX.25 autorouter.

        The WNOS front end allows a system to network at Level 2.
        The WAMPES AX.25 front-end stores paths to other AX.25
        systems and users may use these paths without reference to
        the full path. Each system along the path simply looks up
        the next hop, opens a connection at L2 and relays the
        frames. All this is transparent to any user, be they an
        ordinary L2 user or someone using L2 to push TCP/IP through
        a network. Example

            G6DHU   ->  G4WRW   ->   G7XXX  -> G8YYY

        If G4WRW has a route to G8YYY (via G7XXX), G6DHU can use
        this route without reference to the full path. In other
        words, all G6DHU need do to open a connection to G8YYY is
        say

            connect G8YYY via G4WRW

        as soon as G4WRW sees the connect request, he will open a
        connection to G7YYY via G7XXX. Therefore, each link on the
        path is hop-to-hop acknowledged and the end users only need
        to know their nearest link in the path and the final
        destination in order to be routed through the system. Also,
        any traffic directed through your system in this way, will
        have the path information saved and therefore available for
        future use.

        WNOS is also unique in that it remembers (and saves to disk)
        ALL of the routing table information

            AX.25 paths (as discussed above)
            NET/ROM routing table
            ARP table
            IP routing table

        Therefore, with WNOS it is quite feasible to start with a
        system completely devoid of routing table information and
        then get to know all this information dynamically. Also, as
        paths etc change, tables are automatically saved and updated
        on disk. It is a neat system!

        WNOS was also the first version of NOS to support real time
        data compression using LZW coding. email (via SMTP), news
        articles (via NNTP) and convers interlink traffic may all be
        transferred in data compression mode. Data is compressed
        before sending and results in an average of 45-55% reduction
        in data transferred against plain-text transfer.

        Another item of interest is the NNTP system. WNOS contains
        everything that allows a user to deal with news articles.
        There is a news poster and a news reader. The NNTP
        filesystem is automatically updated, for example, if an
        article arrives for a newsgroup unknown to the local system.
        The news spool is updated immediately and the articles
        accepted.  WNOS also contains a special server which allows
        AX.25 mail to be converted to an NNTP news article and
        cross-posted to a newsgroup.


        This is most suited as an end-user node, rather than as a
        network service provider -- that is, it's a better terminal
        than bbs.

        Has a split-window user interface.
        A status line at the top of the screen displays info
        about the current window, and indicates when there is new
        activity on other windows.
        (Each "window" is really a full screen.  You can switch among
        screens, but they don't overlap.)
        There is an input area at the bottom of the screen.
        attribute command sets monitor type <color|mono>.

        Supports convers, though probably not compatible with JNOS.

        The 'w' in the name is for WAMPES, which is an AX.25 routing
        mechanism (used in FlexNet?).

        By the way, I had a quick look in WNOS docs and it seems WNOS
        is ONLY a packet switch, it supports neither SMTP nor BBS message
        commands.

    hrlnos                            19-Mar-92
        by R. Kolb PA3EUG [e-mail]; PA3EUG @ ON4UBO;
        Derived from PA0GRI 16-Aug-91.

        Has a split-window user interface like WNOS.

        FlexNet: hop-to-hop-ack digipeating

        mbox log
        mem efficient
        mem thresh

        mode ipcam    uses AX25 PID Text rather than IP.

        Does AX.25 autorouting.

        timers reworked.  IP times are now dynamic.
        Saves arp cache to disk.

        minihrl is a smaller version of hrlnos.
        It has no netrom support, thereby gaining 80k of memory.

    gpsnos                                 11-Nov-91
        Based on KA9Q NOS 910420.

        Optimized as a packet switch by GRAPES, B. Nebergall, K4TQL.

        Adds netrom/ax25 switch optimizations, removes mailbox
        functions.  Has a remote sysop facility with a good "public"
        password protection scheme.  Supports up to 5 hardware
        ports, including 56K ports.

    pmnos
            Presentation manager NOS,
        Walt Corey KZ1F  <[e-mail]>

        The authoritative drop site for PMNOS is UCSD.EDU.

        The current beta version of PMNOS is PMNOS 1c: PMNOS1C.ZIP

        THIS IS STILL BETA! Please don't distribute this code
        without making sure that it is accompanied by:

            PMAIL.ZIP    9/18/92 -- 14:40:04
            pmreadme.1st 10/6/92 -- (update includes this
                        message)

        Users should have access to nos_1229.man(lp) (GRINOS manual)
        and the readme files from JNOS 1.04... There is NO OTHER
        documentation YET....

        The "cleaned&cleared" release will be posted on UCSD.EDU and
        the source code will be integrated with JNOS.

        After Johan releases JNOS 1.05 (soon hopefully) a "current
        working" compile of PMNOS will appear at UCSD.EDU and
        at WG7J.AMPR.ORG.... The OS/2 and PM sources will be
        combined with the rest of JNOS and an OS/2 compile selected
        by #ifdef statements... IF everything goes well in the
        project.  Currently, The IBM C set/2 compiler is the only
        compiler that has been used to build PMNOS. I have
        experimented with the GNU C/C++ compiler, but have had no
        luck so far (I am not a "real programmer"). Other compilers
        such as the forthcoming Borland, Zortech, and Watcom
        compilers for OS/2 should work in competent hands.... But
        these are still unknowns.

        WARNING-- if you have not programmed the PM environment,
        you had better go "larval stage" with the OS/2 'redbooks'
        (and other PMwindow specific DOCS!!) for a while before
        getting creative.... Stick to customized builds of the code
        for YOUR OWN PURPOSES. PLEASE don't distribute new compiles
        of this stuff!!! This ain't just DOS anymore!! The
        'redbooks' can be downloaded from software.watson.ibm.com by
        anonymous FTP.

        Authoritative answers to questions on communication problems
        for OS/2 version 2.0 can be found on HOBBES.NMSU.EDU and
        SOFTWARE.WATSON.IBM.COM.

        Network driver support should be along later in the
        year: Planned are SCC, PI, and an NDIS 'shim'.

        The SCC and PI drivers will be loaded at IPL (in the
        config.sys schema) as:

        device=C:\OS2\SCC.SYS <parms similar to attach statement #1
                   in autoexec.nos>

        The NDIS 'shim' will enable use of NDIS drivers in a manner
        similar to the NDIS_PKT packet driver set. You will have to
        scrounge up your own copy of the appropriate OS/2 NDIS driver,
        protman.sys, etc.....

        All of the above is subject to negation, reversal,
        alteration, etc., by Walt Corey.


    wampes                            16-Sep-92
            Dieter DK5SG / N0PRA <[e-mail]>
        ucsd.edu:/hamradio/packet/tcpip/wampes

        WAMPES is a Unix based system derived from KA9Q. It supports all
        the usual TCP, UDP and IP services and was the first to provide
        the convers system (like the Internet's IRC). It was written by
        Dieter Deyke (DK5SG) and ran exclusively on machines running the
        HP-UX Unix flavour. It has since been ported to ISC and SCO Unix
        running on PCs and within the last few monts it has been sucessfully
        ported to Linux, the free Unix for 3/486 PCs.

        It currently  supports HP 9000 series 300, 400,
        700,  and 800  computers,  running  HP-UX  08.xx.
        It at least compiles on SunOS, but hasn't been thoroughly tested.

        Alan Cox <[e-mail]>

        On the subject of wampes there is also a version for
        interactive unix and allegedly one for linux (tho I've
        not traced this).


        [How is this related to HRLNOS? ]

    k5jb
        Joe Buswell, K5JB, Midwest City OK
        Packet Address: [e-mail]
        Amateur Radio IP Address: 44.78.0.2
        Internet: [e-mail]
        CIS: 70305,1341

            This is a variant of ka9q (890421) that runs on SCO Unix.

    pe1chl                            1-Jul-92

        Network
        netrom fixes

        "ftl0" and "broadcast" protocols/command sets for access
        to the microsats like AO-16 and UO-22

        can receive (but not transmit) the PACSAT broadcast
        protocol, which is sent    by the PACSAT amateur satellites.

        UI changes
        fkey
        version
        screen

        services
        bbs forwarding scripts

        Costas SV1XV (ex G7AHN) <[e-mail]>

        Regarding MINIHRL, the author PA3EUG states it is HRLNOS without
        the NETROM code. I have been unable too to find the full HRL NOS
        code, it is not on UCSD.EDU or on any other well known site.

        PE1CHL is a release of NET.EXE with very limited  user services
        very simple mailbox but it is reasonably well designed for ax25
        and also supports the "ftl0" and "broadcast" protocols/command sets
        for access to the microsats like AO-16 and UO-22.

        We might run it here in Athnes on SV1IW's station to
        create a TCP/IP sat gateway.

        Good docs on PE1CHL are files NETDOC1.ARC and NETDOC2.ARC
        in directroy /hamradio/packet/tcpip/pe1chl on ucsd.edu

        G0BSX mail server:
        ucsd.edu:/hamradio/packet/tcpip/g0bsx/server.tar.Z

    g1emm
            Kelvin Hill G1EMM    <[e-mail]>
        ucsd.edu:/hamradio/packet/tcpip/g1emm

        This was once a very actively developed version, but doesn't
        seem to have grown much in the past year or two.  It
        branched off into PA0GRI (and hence GRINOS).

        SV1XV, Costas <[e-mail]> writes:

        Kelvin also distributes SMALLEMM.EXE (without
        AX.25/NETROM/KISS, which only supports SLIP and
        Ethernet interfaces) and is very small. I use it on my
        laptop Amstrad PPC-640D. He also distributes an
        example of a full G1EMM NOS installation in the file
        G1EMMKIT.ZIP.

        N8GNJ,    Steve Stroh     <[e-mail]> writes:

        I think that when Kelvin got out of NOS codesmithing,
        PA0GRI took his code and started the now popular
        PA0GRI variant of NOS.  The G1EMM code is effectively
        obsolete, but it is probably maintained on several
        systems.


    unknown

        Alan Cox <[e-mail]> writes:

        There will be a ka9q net with smtp links to the O/S, host
        mode login via ax25 and the ability to act like a netrom
        node for Linux very soon. I'm just finishing debugging it.
        If I get it finished I'll mail you if you want to stick it
        on the list.

----------------------------------------------------------------------
NOS Internals

    There is not a whole lot of documentation on NOS internals.

    The socket interface used by the TCP clients and servers closely
    resembles the one found in BSD Unix.

    The tricky parts arise in dealing with the multi-tasking kernel.

    More details on the NOS internals may be found in the following files:

     [What internals documentation is there?]

Source code organization

    The sources are distributed in a single flat directory.
    The names of the files do not have prefixes that would identify
    the part of NOS to which they belong.

    The modules are divided into groups.  Each group of modules is
    placed in a library.

    Most variants of NOS are distributed in two or more packages.
    There are no guidelines for what to put in a distribution, or how
    to package them, so each NOS variant is distributed differently.

    NOS is generally packaged appropriately for the system that runs it.
    DOS versions of NOS are almost always packaged in zip files.
    Unix versions appear as compressed tar archives, and less
    frequently as zip files.

    One package typically contains an executable, and possibly some
    sample init files.  Another package contains the documentation
    specific to that variant.
    Another package often contains the full set of sources that was
    used to build the executable.

    It might seem silly to distribute the entire set of sources even
    when only a couple of things have changed.  It is not practical to
    distribute packages of only those modules that have changed,
    because there is no standard base version to serve as a reference.
    Even if there were, that reference version would itself be
    changing, so people would have to keep several copies of it on
    hand.

----------------------------------------------------------------------
Running different NOS versions with the same configuration

    It is sometimes possible to use the same set of configuration
    files and tree of directories with several versions of NOS.
    Some versions are so different, however, that they will not be
    able to understand each other's config files.  For instance, WNOS
    has trouble with the config files for JNOS.  The mailbox help
    files (in spool/help) are often quite specific to a particular version.

    Even worse, the commands that a NOS understands depends on what
    features were turned on when it was compiled.  If your config file
    contains commands to set up the NETROM interface, they will
    produce error messages if you run a NOS that was compiled without
    NETROM support turned on.  There isn't really any way to fix this
    problem, and it isn't all that unreasonable.

    The following are some known inconsistencies that could be fixed
    by someone who has the time to do it.  [Add to this list, please!
    Try to be as specific as possible.  The less time someone has to
    spend fixing something, the more likely it will be fixed.]

    -   The ftpusers file requires its fields to be separated by
    spaces in most versions of NOS.  You can't use tabs.
    [This has been fixed in JNOS 1.07.]

    -    The 'domain suffix' string must NOT have a leading period, but
    can (must?) have a trailing period.  If you do it wrong, some
    versions will complain, but most will just quietly fail to work
    properly.  I think it would be reasonable for the command to
    munge the string to look the way it should.

    -    In most versions of NOS, the arguments to some commands in
    autoexec.nos MUST be separated from each other by SPACES.  If
    you mix tabs and spaces, the command will be parsed incorrectly
    due to a bug in the parser.
    [This has been fixed in JNOS 1.07.]

    -   There are minor variations in similar subcommands:

        ax25 retries
    vs.    netrom retry

    I'd vote for the plural form myself, because the singular form
    might suggest that it is a boolean that controls whether a retry
    should happen, whereas it is actually an integer count.

    -    The help strings that the commands print when given no arguments,
        as well as documentation, use "label" and "interface", "host",
    "address", and "destination" ambiguously.  "address" could be
    an IP address, an AX.25 callsign, or an Ethernet address.
    "label" usually turns out to be the name of an interface.

    Ian Wade G3NRW has suggested the following conventions in his
    paper in the 10th (1991) ARRL CNC proceedings.

    <callsign>     an AX.25 MYCALL callsign (e.g. G3NRW-5)

    <hostname>     a host name in domain.txt
               (e.g. g3nrw or g3nrw.ampr.org.)

    <ipaddress>    an internet address (e.g. 44.131.5.2)

    <host>           <hostname> or <ipaddress>

    <username>     a user at a computer (e.g. ian)

    <interface>    a device interface name (e.g. ax0)

    <ioaddress>    a device I/O base address (e.g., 0x3f8)

    <vector>       an IRQ level (e.g. 4)
               [why not <irq> ? - mg]

    -   Different commands do different things when invoked with no arguments.
    This in itself isn't so bad, except that you can't always tell
    whether doing so had an effect or not.

        Some commands print a help message when invoked with no arguments.
    Unfortunately, some simply print "needs at least one argument",
    instead of just telling what the choices are.  (If you type just
    "ax25" it says that, if you type "ax25 ?" it shows you the
    subcommands.)

    Other commands that can take arguments display some status
    information when they are invoked with no arguments.
    Unfortunately, some of them don't appear to do anything -- you
    just get another prompt.  This could happen if they would
    report some string and that string is empty, such as the
    "motd" command.  Such commands should really print something
    like "<not set>", instead of appearing not to do anything.

    Moreover, if a command that could take arguments *does* do
    something when invoked with no arguments, it should say that
    it has done it.  For instance, a command might set a variable
    a default value if invoked with the value omitted.  (No
    commands that I know of do this; omitting a value causes them
    to print the current value.)

    Note that commands can't tell if they are being invoked from
    autoexec.nos or by someone typing interactively.  This is
    probably why most of them aren't very verbose.


----------------------------------------------------------------------
Packet drivers

    The packet drivers from Clarkson and others are used to allow
    NOS to interface to many pieces of hardware and software.

    NOS can be interfaced to the G8BPQ switch and to BAYCOM modesms.

Why are there still compiled-in device drivers?  Why aren't they
implemented as packet drivers?

    William Allen Simpson <[e-mail]> writes:

    Part of the reason is that packet drivers don't separate the
    encapsulation (link-layer) from the actual device (hardware-layer) very
    well.  So, for example, when you have SLIP, PPP or NRS over two async
    ports, you would need to load all of the link-layer code twice.

    Also, a link-layer like PPP requires significant resources such as
    buffers and timers, which either need to be pre-allocated and managed
    for every device (wasting lots of CPU and memory), or managed under a
    single mechanism.

    BTW, Merit has built a PPP packet driver for NCSA Telnet.  It's over
    100K, instead of the 24K we have inside NOS.

    Therefore, I believe that KA9Q (Phil Karn) decided on this architecture
    to save CPU and memory.  Remember, he started the program under CP/M!

    Now, there was some talk a year or two ago about a re-designed device
    driver mechanism to replace packet drivers.  But there was also talk
    about going to NDIS drivers.

    Which shall we do?

I can't seem to attach more that 3 packet drivers at once in NOS.

    Mike Bilow <[e-mail]> writes:

    That's true, you cannot attach more than 3 packet drivers.  This would
    have to be changed in the source code.  In fact, someone should
    probably finally sit down and make it correctly configurable with a
    simple compile time #define somewhere.



----------------------------------------------------------------------
Common problems

Async interface loses characters

    If your machine can't field the interrupts from the serial port
    fast enough, it loses characters completely.  One symptom is that
    datagrams get retransmitted frequently over a SLIP or PPP line.
    In some NOSes this causes the TCP connections to reset
    automatically after getting a few datagrams across.  (TCP performs
    very poorly when the IP level datagrams are not delivered
    reliably, so it's best to just give up rather than waste
    bandwidth.)

    Another symptom is that garbled callsigns appear in the 'ax heard' list.

    One solution is simply to use a slower speed, like 4800 baud.

    A better solution is to replace the 8250 or 16450 UART with a 16550
    UART that has a built-in character FIFO.  This chip can buffer up
    to 16 characters while the machine is busy doing other things, so
    it relaxes the demand for prompt service.

    I've found that the JNOS i8250.c driver is slower than the others.
    It loses characters badly on a 9600 baud telephone modem, whereas other
    versions can keep up with no character losses at all.

    Rumor has it that DesqView may also cause problems if you run NOS
    in window 1.  Serial communications-intensive applications should
    ideally be run in window 2, as that one is actually optimized for
    serial comm.


    John Ackermann, AG9V, writes:

    I'm not sure why Johan's 8250 driver is slower -- I personally haven't
    noticed that -- but I do know that at least through his 1.04 release
    the 16550 fifo was <not> enabled; the code would detect the '550 but
    wouldn't do anything with it.  In JNOS 1.05, the fifo size can be
    specified as an attach command parameter.

Why do large amounts of core suddenly disappear?  For instance, I
started with 110K core, and FTP'ed a 1.5 Megabyte file off a LAN host
(14K bytes/sec transfer).  Core dropped to 30K. (using PA0GRI 2.0l)

    John Ackermann   AG9V <[e-mail]> writes:

    We found that the disappearing core was due in very large part to the
    number and size of Ibufs you've configured.

    What happens (I'm not a Real Programmer, so this may not be technically
    right on) is that when NOS needs another ibuf, it has to find a big
    enough unfragmented chunk in the heap to hold it.  If it can't find a
    large enough piece of memory, it goes to the core to get one.

    When you have ethernet-sized ibufs, it's quite likely that there won't
    be an unfragmented chunk big enough, so core is going to go away
    quickly.

    When we ran 1600 byte Ibufs, even starting with 190k coreleft, we could
    only run for about three days max before core would disappear.  We
    reduced the ibufsize to 448, which despite manual references to the
    contrary seems to be the minimum that works with an MTU of 256 and now
    we <never> see crashes resulting from loss of core (there are OTHER
    kinds of crashes, though...).

    So, sacrifice some performance on the ethernet by reducing your
    ethernet mtu, and your mss, to match what you'll really be running on
    the air.  Then, set ibufsize to about that mtu plus 128.

    I haven't yet been able to determine whether the number of ibufs you
    set has any noticeable impact on this situation.  That's one for the
    coders to answer.

    "Carl Makin" <[e-mail]> writes:

    Just one note.  The Ibufsize must be larger than your largest buffer
    size. (Not the same as but larger otherwise the SCC driver doesn't work
    properly.)

    So I assume you are running attach buffersizes just a little bigger or
    the same size as the mtu of the interface. ie 447 mtu for an ethernet
    port with a buffersize of 447.


    John Ackermann   AG9V <[e-mail]> writes:

    Actually, I've been running attach buffers much larger than ibufsize;
    never knew that was a requirement.  And, it doesn't seem to affect
    things negatively.  When I ran big ibufs, they were bigger than the
    attach buffers and <that's> when I had the memory leak problems.

    It would be nice for One Who Truly Knows to fully document these buffer
    issues... their tuning is critical, but there sure isn't much to go on.
    Witness the statement in the asystat command section of the reference
    manual (that's been there for ages) that the number of software
    high-water-mark hits tells you whether you need to adjust the buffer
    size, and then refers you to the attach command chapter for further
    details, of which there are none.


    Johan K. Reinalda, wg7j <[e-mail]> writes:

    Asy attach buffer doesn't care what the ibuf size is; they are fifo
    type buffers used during the interrupts, from which the asy rx process
    reads characters into mbufs. An asy buffer is allocated (with ints on)
    during the attach command, and is there for the life of the interface.

    Scc, packet and pi interfaces use the interrupt buffer scheme very
    actively for receiving of packets. They allocate buffers at interrupt
    time, and the queue need.

    The size of the buffer is somewhat complex. It needs to be the largest of

        -the largest ax25 paclen + about 100 (ax.25 header, actually 72 bytes max)

        -the largest ip mtu (if in vc mode over ax.25) + 20 (ip header) + about 100

        -the ethernet mtu + safety margin :)


    I have some written up in the latest draft of the jnos40 DE manual, I
    will include that in the docs for 1.05.


Why won't my PK-88 (and PCB-88)  send/receive a packet larger than 1048 bytes?

    The AX.25 spec limits packets to 256 data bytes, but we'll ignore
    that.

    It's a built-in limitation of AEA's.
    Some Kiss implementations have even more severe limitations.
    The Kantronics ROMS (at least the earlier ones) won't allow 1024.
    You can try getting newer ROMS for your TNC from the manufacturer,
    but they can legitimately claim that they conform to AX.25
    (KISS doesn't really specify the max packet length; AX.25 does).

    The TNC2 TAPR ROMS do not seem to impose any limitation
    other than memory.


Why do I see what look like lower-case o characters scattered
throughout the output of various NOS commands, such as the output of the
/who command in converse?

    The "lower-case o" characters are TABs (ascii 9).  You need to use
    the ansi.sys DOS screen driver (or one of its variants), which can
    properly expand the TABs.  Place 'device=c:\dos\ansi.sys'
    somewhere in your config.sys file (using the correct path, of
    course).  A popular ansi.sys variant is nansi.sys, available
    in the directory ucsd.edu:/hamradio/packet/tcpip/nansi.

---------------------------------------------------------------------
Compiling NOS

What compiler do I need to use?

    Most versions of NOS were developed using Borland (Turbo) C.
    You'll have the best luck with Borland C++ V3.1.
    Earlier versions may work, but beware of invisible compiler glitches
    (see next section).

    Originally, Borland sold the compiler, assembler, debugger, and
    profiler as "Turbo C Professional".  Later they split the package into
    pieces.  Now the compiler is available for less than $100 as "Turbo
    C++".  The compiler and all the tools is available as "Borland C++",
    currently V3.1, and costs more than $300.  (For another $200, you can
    also get Borland's "Application Framework" for building Windows
    applications, but that isn't needed for NOS.)

Compiler glitches

    Turbo C++ 1.0 cannot compile NOS, because the compiler is too buggy.
    (It compiles it, but the resulting executable doesn't work right.)

    I believe that Turbo C++ 2.0 will successfully compile it, but you
    need to apply to the compiler patches supplied by Borland.

    Borland C++ V3.1 seems to produce reliable NOS binaries.

    BC++ V3.0 will work too, but people have reported that it produces
    an executable that crashes after about a half-hour (JNOS 1.07).

    Mike Bilow, <[e-mail]> writes:

    The BC++ 3.1 "-3" compiler switch is not safe with NOS.  This appears
    to be limited to certain specific modules, primarily ALLOC.C, but I
    have never managed to encapsulate the problem sufficiently.  What I
    think is happening is that the use of the "HUGE" keyword in some places
    causes a conflict with the "-3" switch.  Compiling ALLOC.C to assembly
    source with the "-3" switch will show some very funny results, for
    example.

    On the other hand, the "-Z" compiler switch, which used to be unsafe,
    is now safe under BC++ 3.1.  You win some, you lose some.

    You will find, I think, that Borland's "-O2" switch (optimize
    for speed) is generally not a good idea.  I have found "-O1" to
    be stable as of BC++ 3.1, where it was not in prior versions.
    If you need faster code, you would be better off trying to force
    inlining of particular modules, especially inportb() and
    outportb(), which stand in the way of fast I/O if you have to
    put up with function call overhead on each use.

Compiler warnings

    Most versions of NOS have code that the compiler considers questionable,
    so it will produce a few warning messages.  Most of these are
    harmless, and are caused by functions not being declared properly.
    These warnings will probably be corrected later, but they don't
    cause real problems so they are not high on the authors' lists.

    If you only get warnings such as the following, don't worry.
    (These are from a compilation JNOS 1.07 with BCC 3.1.)

    Warning config.c 317: Suspicious pointer conversion
    Warning smtpserv.c 447: Function should return a value in function getmsgtxt
    Warning convers.c 911: Constant out of range in comparison in function
    channel_command
    Warning converse.c 1115: Constant out of range in comparison in function
    name_command
    Warning forward.c 466: Unreachable code in function makecl
    Warning tcpcmd.c 473: Suspicious pointer conversion in function doview
    Warning ipcmd.c 360: Suspicious pointer conversion in function doroute
    Warning arpcmd.c 342: Suspicious pointer conversion in function dumparp
    Warning arp.c 119: Condition is always false in function arp_input
    Warning arp.c 384: Possibly incorrect assignment in function arp_timeout
    Warning timer.c 61: Possibly incorrect assignment in function timerproc
    Warning alloc.c 405: Nonportable pointer comparison in function dofreelist
    Warning nrcmd.c 221: Suspicious pointer conversion in function doroutedump
    Warning nrcmd.c 328: Suspicious pointer conversion in function doallinfo
    Warning nr4.c 719: Suspicious pointer conversion in function nr4state

What does 'linker fixup overflow' mean?

    Mike Bilow, <[e-mail]> writes:

    >Fixup overflow at _TEXT:0092 , target=__MKNAME
    >c:\bc\lib\cl.lib in modeule FCLOSE.

    You need to force all of the MKNAME.C module to be in the _TEXT
    segment.  This is explained in the voluminous comment I put into
    MKNAME.C.  You need to make sure that MAKEFILE invokes the compiler
    with the -zC_TEXT switch when compiling that specific module.

    What is happening is that library routine fclose() is making a call to
    __MKNAME(), which is declared to be "near pascal."  This means that the
    linker must be able to resolve an address for __MKNAME() within 64K; ts
    is a "linker fixup."  If __MKNAME() is more than 64K away from the
    place in flclose() where it is trying to call __MKNAME(), that is a
    "linker fixup overflow."

    This is not, by the way, a problem that can be finessed.  It must be
    fixed.


What do I do when DGROUP exceeds 64K?

    The error happens because too many data objects (variables, strings, etc.)
    have been placed in the data segment, which is restricted to be only 64k
    bytes long.

    The easiest way to avoid this is to choose fewer options in config.h,
    so fewer data objects are defined.

    However, setting -Ff=511 or -Ff=255 in the makefile this will
    usually do the trick, too.

    Another way is suggested by Mike Bilow <[e-mail]>:

    The DFAR kludge that I developed to finally fix the linker error about
    DGROUP exceeding 64K found its way into the distribution release of
    PA0GRI NOS as of v2.0l or so.  Although it will work with Borland C++
    from version 2.0 or later (and this is correctly handled by a #define
    in GLOBAL.H), the compiler must be invoked with the "-Ff" switch from
    the MAKEFILE.  (Variants with the threshold specified, such as
    "-Ff=511", will work fine.)  I have not looked at Johan's [wg7j] source
    lately and I don't know if he included the DFAR kludge also, but it is
    generally more stable to use the DFAR kludge where the programmer picks
    what gets expelled into the far data segments rather than the Borland
    "-Ff-nnn" automatic far data threshold.  In my experience, "-Ff=nnn"
    will work with only sufficiently large values for "nnn," and will fail
    if smaller than 255.

    In other words, it works better to tell the compiler to be on the
    lookout for far data conversion with the "-Ff" switch, but to manually
    specify what gets moved using the DFAR kludge.  The "-Ff" switch with
    no value specified defaults to 32K, which doesn't move anything
    automatically.  (Believe it or not, no one has yet put a static data
    object in NOS that is bigger than 32K.)

Where can I get the pklite program that the NOS makefile uses?

    pklite is in ucsd:/hamradio/packet/tcpip/util/pklte105.zip,
    and many other places.  It's a companion program to pkzip et al.


Can NOS be made to use code overlays, so only the parts that are really in
use reside in memory?

    Mike Bilow, <[e-mail]> writes:

    Making NOS work with code overlays is a discussion that comes up from
    time to time.  I spent a long time trying to get it to work, and all I
    ever had was a program that crashed almost instantly.  The problem is
    that NOS changes the stack segment register on the fly, and the overlay
    manager has to know certain things about the stack in order to work.
    The general consensus is that overlays cannot be done, although I have
    never conceded that and can't provide a counterexample.



----------------------------------------------------------------------
DesqView, windows

    Mike Bilow, <[e-mail]> writes:

    You have some immediate problem when trying to port NOS to DesqView or
    Windows.  First, Windows is somewhat unsuitable, since Windows apps
    expect to cooperatively multitask, and real-time performance is a thing
    requiring lots of kludges, even by Windows standards.  There are direct
    solution for doing this kind of Windows programming, most obviously
    writing a custom VxD virtual device driver, but you may find that you
    have rewritten a good chunk of Unix by the time this works.

    DV is more suitable, but still leads to problems.  It can be run on a
    very simple machine, although you don't gain much with DV until you have
    a 386 or better.  At this point, you are probably looking at the whole
    difference between a good DV setup and a good OS/2 setup being 4 MB of RAM,
    about $120 at current U.S. street prices.  I think DV is a really well done,
    even briliiant, product that fit a market niche that will soon disappear.

    Walt Corey [44.104.0.23] <[e-mail]> writes:

    As I have mentioned before windows is not a multitasking system, it is
    cooperatively multitasking. This means that only one program can run at a
    time (period) That one program can give up control to Windows at selected /
    predetermined points, at that point Windows can give control to another
    app. That program in turn runs until it decides to give up control. If for
    some reason (error perhaps) it doesnt, nothing else (including windows)
    will run. If a program "hogs" control for say 1 sec, at 9600 baud thats abt
    1k data lost, for 5 sec its about 4.5k lost. It essentially could be done
    but there would be a huge risk of data loss and each process would have to
    be a window, as in the "dispatchable" unit of execution under Windows.
    Under OS/2 (for instance) it is a task not a window and OS/2 is a pure
    multitasking operating system, the timer task can not be stopped by a bad
    app, neither can the asy devices or the keyboard etc etc.


    [e-mail] writes:

    There is another dos multitasker that would seem to fit the bill here
    it's Free, well documented, source available (also free), and has
    almost all the facilities needed built in. The program is called CTASK
    written by (I think) T. Wagner in Germany.  I had considered a while
    back cutting the socket lib out of NOS and moving it to CTASK but the
    job looked a lot bigger that the time I had available.


Why does NOS implement its own task-switcher, when there are
several that exist and do a passable job?

    DOS NOS was done before DesqView was viable.  Also, requiring that someone
    have DesqView in order to run NOS would have limited the number of people
    who could run NOS.

----------------------------------------------------------------------
Questions

    [ This section should summarize the topics that arise
      perennially on tcp-group. ]

How can I use NOS between computers over an RS232 wire link?

    NOS can use an asynchronous RS232 link by using a driver known as
    the async serial driver.  Look for the documentation under
    the 'attach' command, using the 'asy' driver.

    The link protocol uses the async driver.
    Whereas the async driver will move the characters from one machine
    to another, the link protocol interprets them.

    Most versions of NOS support one of two link protocols.

    SLIP is the most commonly used serial port link protocol.

    PPP is an alternative.  It is similar to SLIP, but permits the hosts
    to negotiate things like the interface's MTU automatically.
    If you don't know what that means, don't worry.  You're probably
    better of using SLIP.


Which of the RS232 signals are required on an async serial connection
(i.e., the minimum required)?

    RXD, TXD, and ground (pins 2, 3, and 7) are the minimum required.
    If both ports expect to be connected to a modem (most PC serial
    ports do), you'll have to use a null modem to flip pins 2 and 3
    (also 4 and 5; see below) between the ports.

    Beware that there is no hardware flow control with only these
    three signals.  Unless the link protocol does software flow
    control [I doubt that SLIP or PPP do], characters may be lost.

    If you also connect RTS and CTS (pins 4 and 5), NOS can use them
    for hardware flow control.

Does the async serial driver in NOS/NET do any hardware handshaking for flow control?

    Yes.  There is more than one implementation of the async serial driver,
    and each one handles handshaking differently.  The most widespread
    one is the one found in KA9Q NOS.  With it, you specify
    whether it should use RTS/CTS handshaking by putting a 'c' in the
    options word at the end of the attach command [before the IP address?].

    Another async driver, found in WG7J's JNOS [what others? GRI?],
    also supports RTS/CTS handshaking, but you don't have to specify
    that it should do so.  It automatically detects whether the other
    side is using flow control, and acts appropriately.
    If you do specify a 'c' in the 'attach' command's options word,
    the driver will ignore it, so it doesn't hurt to leave it there.
    [ Then how can I tell it to initiate the handshaking? ]

    This async driver can also use the RLSD (also called DCD) signal
    for flow control.




How do I use NOS as a router (gateway) between an Ethernet and an
Amprnet via a TNC?

    Jack Spitznagel <[e-mail]> writes:

    You may use any ethernet card that you have a Russ Nelson/Clarkson/FTP
    Inc. Packet driver for. I have used NE1000/2000, DEPCA, 3COM, and
    WD/SMC8003/8013. Drivers also exist for IBM Token Ring and Arcnet
    adapters.

    As in most TCP/IP implementations the "ifconfig <interface_name>"
    command allows one to assign independent (or the same) ip addresses for
    each interface. Gatewaying is supported by *either* doing an "arp ...
    publish" for the remote slip ip-address at the connected ethernet end,
    *or* using the "ifconfig encap" to encapsulate one subnet thru another
    ones ip address link. (this is the amprnet gateway system you have
    heard talked about.) My explanation presupposes you are familiar with
    most of the TCP/IP routing and addressing issues.


My machine crashes when I run it as an ethernet <-> slip router.

   Try getting a newer version of NOS (especially the KA9Q version).
   Also try running with handshaking totally disabled at both ends.

Why do I see garbled callsigns in the 'ax heard' list?

    This can happen because of errors in the received packet.  Bad
    packets occasionally occur in any transmission medium, especially
    on a shared radio channel.  If the sending stations TxDelay is too
    short, you may also see garbled packets.  Not all bad packets will
    appear in the various error counts kept by NOS.

    Garbled packets may also result if your serial port loses characters;
    see the section on 'async interface loses characters' elsewhere in
    this file.



How do I get a permanent IP address?

    Talk to the AMPRNET address coordinator for your area.
    A list of them is available in
    ucsd.edu:/hamradio/ampr_coordinators [?]
    The best way to find out, though, is to find other people nearby
    who are already running an AMPRNET host.

How do I set up a machine as a mail gateway?

    [this needs work - there MUST be a better way to do all this!]

    Briefly, add a REWRITE RULE to spool\rewrite FOR EACH HOST ALIAS.

    The machine must have a mail host address, one for each mail network
    that you want it to connect.  (A "mail network" is simply a bunch
    of machines that can, directly or indirectly, send mail to each other.)
    The machine considers itself to have only one real hostname,
    which is set (in AUTOEXEC.NOS) via the 'hostname' [?] command.
    We'll call the other names "hostname aliases".

    With NOS, you must take care that your gateway machine recognizes
    that the mail is destined for it, regardless of which of its host
    names (or aliases) the message was sent to.

    To begin with, the machine only recognizes mail addressed to its
    own IP hostname (the one that's set by the NOS 'hostname' [?]
    command).  To make it recognize its other host names, you have
    to add a rewrite rule in the file spool\rewrite that turns that
    hostname alias into the real hostname.

    If you fail to make your machine recognize all its hostname
    aliases, then when a message arrives for one of its aliases, it
    will forward the message to some other machine (usually to its SMTP gateway).
    Some machine down the line will realize that the message is
    supposed to go to your host, and will send it back there, creating
    a loop.  Eventually, some machine in the loop will notice that
    the message has been to the same hosts several times, and will
    (hopefully) return it to the sender.


What is "the mailer"?

    NOS can act as a maildrop, collecting and storing messages
    addressed to you.  There are several ways it can do this, such as
    SMTP and "conventional" amateur BBS mail forwarding
    protocols.  Also, people to connect or telnet to your mailbox can
    issue mailbox commands to leave you mail.  No matter how the mail
    gets there, it is stored in files in the spool/mail directory,
    where it stays until you do something with it.
    All messages addressed to a particular recipient are concatenated
    together in a single file.

    The mailer is a program, separate from NOS, that shows you the
    messages in a mail file.  If you are running plain DOS, you have
    to exit NOS to run the mailer.  (You can also use the 'shell'
    command to suspend NOS and get to a DOS command interpreter, but
    that takes a lot of memory to work.)  Then you run the mailer
    program to read your messages.  You can delete them, reply to
    them, forward them, and so forth.  When you're done, it updates
    your mail file, and queues any messages that you asked it to send.
    NOS will try to send the messages the next time you run it.

    You can run the mailer while NOS is running if you're running a
    multitasker like DesqView or DoubleDos.

    You can choose which program to use as the mailer by setting
    the DOS environment variable MAILER in your AUTOEXEC.BAT, as in

    SET MAILER=VIEW.EXE

    Some of the mailers that are available are:

    BM        The earliest mailer that was included with NET/NOS.
        Written by Bdale Garbee, N3EUA.

        ucsd:/hamradio/packet/tcpip/bm

        This was originally written as a quick-hack with style (or
        lack thereof) reminiscent of /bin/mail on most Un*x
        machines.  The whole motivation behind BM was to have some
        way to test the SMTP client I had written for NET and the
        SMTP server Phil had written and I had hacked on.  I still
        remember how much fun it was sending the first mail
        message from BM to the tcp-group list...  :-) And the very
        serious discussion Phil and I had on the phone about
        whether it was OK to call it 'BM' in a time period when we
        were trying hard to be taken seriously by the packet
        community at large... but hey, if you can't laugh at
        yourself... :-)

        Dave Trulli NN2Z did a bunch of work on BM at one point,
        which is probably why it's still alive and in use.

    PCELM   A replacement for BM, popular in Europe.

    VIEW    ?
        ucsd:/hamradio/packet/tcpip/bm

        One small addition: The VIEW mailer is a full screen e-mail
        user interface with many features like undigestifying,
        queue manager, gateway specification etc.

    NNTP readers

      -    I have not checked yet for newreaders specific to NOS,
    but the ones developed for PC-UUCP use should be usable.

    in /ibmpc/simtel20/msdos/uucp on doc.ic.ac.uk
    (probably also on SIMTEL20 and its mirrors, like nic.funet.fi)
    It might need some modification to cooperate
    flawlessly with NOS NNTP but this should be minor.

      -    snews from John McCombs


      -    ftp.demon.co.uk:/pub/trumphurst/cppnws16.zip
    Nikki Locke <[e-mail]>

Why does the 'shell' command just return without doing anything?

    This happens if there is not enough memory to run the DOS command
    interpreter as a child of NOS.  Rather than printing a message
    informing you of this, NOS just prints another prompt!

What is AMPRNET?

    AMPRNET is a network composed of amateur TCP/IP hosts whose names
    are in the .ampr.org domain, and whose addresses are assigned by
    the AMPRNET address coordinator (a person!).

    Although AMPRNET is technically a network, not all AMPRNET hosts
    can talk to one another.  Many people have begun to use landline
    gateways to connect the disjoint pieces of AMPRNET.

What is a gateway?

    A gateway is a host that joins one or more AMPRNET subnets to the
    rest of AMPRNET.  Loosely, an AMPRNET subnet consists of the
    AMPRNET hosts in a particular area, say, a city.

    AMPRNET is a network composed of amateur TCP/IP hosts.  In theory,
    any host on a network like AMPRNET should be able to send IP
    datagrams to any other host on the network.  In practice, however,
    the network is fragmented into "subnets", which, loosely, is a set
    of machines that can talk to each other.  (The term "subnet" has a
    more specific meaning in TCP/IP, where it refers to a set of
    machines that have a common prefix in their IP address.  This
    simplifies routing; for more info, see the reference on gateways.)

    The hosts on a subnet may talk to each other via radio modems, TNCs,
    telephone modems, ethernet, wire lines, or just about any other
    way of moving bytes around.  (NOS is one of the few packages
    available to amateurs that can support this diversity.)
    Each city or town tends to develop such a subnet, because everyone
    in the locality can hear one another on VHF radio, and the phone
    calls are local, or they're even in the same building.

    If each of the hosts in a locality has a coordinated AMPRNET
    domain name and IP address, then that subnet is technically part
    of AMPRNET.  This means that other AMPRNET hosts on other subnets
    (i.e., other cities) could send packets to them, if only there
    were a way to get them between the two subnets.  To do this, there
    must be at least one host that can talk to both of the subnets,
    through which hosts on either subnet can send their packets to the
    other side.  Such a host is a gateway.

    In effect, a gateway turns the subnets into a larger network,
    called an "internetwork", or "internet".

What is an "Internet gateway"?

    An "Internet gateway", in AMPRNET, is a gateway that talks to
    other AMPRNET gateways by sending the packets over a landline
    network known as the Internet.  The Internet (capital I) is a
    world-wide academic and commercial network.

    Therefore, any host potentially can be a gateway if it is
    connected to some subnet of AMPRNET and to the Internet.  In
    order to become an operating is, gateway, the other gateways
    must be told what the gateway's addressand what AMPRNET subnets
    it knows how to send packets to.

    For more information on gateways, look in the following files
    that are available for FTP.

    minnie.cs.adfa.oz.au    gateways.023    (number changes with version)
    ke9yq.ampr.org

What's the difference between a gateway and a wormhole?

    Wormholes don't do routing; gateways do.

    A wormhole is just a two-way "data pipe", often a phone line, that
    can accept packets on one end, and spits them out at the other
    end.  There is only one possible destination.  It is like an AX.25
    digipeater, and in fact many wormholes are fashioned to look just
    like one.  (Another way to look at it is as a band opening on HF.)

    A wormhole doesn't know or care what is in the packets; in
    particular, it doesn't do any routing.  To use a wormhole, you
    have to know where its input port is so you can send your packets
    through it (as if it were a digipeater), and what stations are at
    the other end, so you can address packets to them.

    Gateways are more interesting than wormholes, because they can
    route packets sent into them to one of many different
    destinations, perhaps routing through other gateways on the way.
    Gateways form a true network, in the sense that you can just
    inject a packet into it, and it will figure out how to get it to
    its destination (if possible).

    Because they do routing, gateways have to know something about the
    packets you send through them, so they can figure out where to
    send it.  That is, you have to use a particular protocol that the
    gateway understands.


What parameters should I use for the netrom interface?

    The netrom interface allows you to send IP datagrams through a
    netrom network.  It also makes your NOS station look like just
    another netrom node to the others.

    However, many people have found that using the netrom code makes
    NOS crash frequently, usually just after a netrom stream has been
    closed, especially when the connection was made by a user in the
    mailbox.  It's best not to use the netrom code unless there is
    absolutely no other way you can get to other IP stations.

    Some people use NOS as an alternative implementation of the netrom
    protocol to build netrom node stacks.  This usage belongs more to
    the realm of netrom wizardry than to NOS, so we won't discuss it
    here.

    If you're brave enough to use the netrom interface anyway, use
    these parameters as an example:

    netrom nodetimer 1800
    netrom obsotimer 1800
    netrom minquality 144
    netrom interface axip_place 230
    netrom interface diode_matrix 230       # direct rs232
    netrom interface back_bone 203          # just *two* radios talking
    netrom interface user_port 192          # lots of radios

    netrom ttl 24

    Since the timers will affect both the RF port and the encap ports I would
    suggest you set it to the same value that is used locally on the air.

When somebody sends an AX.25 packet to my NOS system through a
digipeater, my NOS insists on sending it back through the digipeater
even though the direct path really works.  How can I force it to use the
direct path?

    Carl Makin <[e-mail]> writes:

    Define the route manually:

    ax25 route add <call>

    It's then defined as a local route and should be used in preference to
    an "auto" route.


----------------------------------------------------------------------
Wishes

    Costas, SV1XV, <[e-mail]> writes:

    As my job forces me to run SCO Unix Sys V on my main
    machine, I would like to find a STREAMS/socket driver to add
    ax.25 and KISS to the existing SCO TCP/IP services, but it
    seems nobody has written one yet.

----------------------------------------------------------------------

Glossary

    NET
    NETROM
    NOS

    RSPF
        ucsd.edu:/hamradio/packet/tcpip/docs/rspf.doc
    ucsd.edu:/hamradio/packet/tcpip/incoming/rspf22p.txt

    RIP
    TCP
    IP
    Internet
    internet

----------------------------------------------------------------------
Bibliography

ARRL Computer Networking Conference Proceedings
    Available from ARRL HQ, Newington CT.
    Send mail to [e-mail] for an automatic response pointing at
    more information about the ARRL.
    Some of these papers are available online in the directory
    ucsd.edu:/hamradio/packet/tcpip/docs.

    This list is not exhaustive; there are many other interesting
    articles, but these are the ones most relevant to NOS and TCP/IP.

    NOS Overviews and Documentation

    NOS Command Set Reference
            Ian Wade G3NRW            10th (1991)

    NOSVIEW: The On-Line Documentation Package for NOS
            Ian Wade G3NRW            11th (1992)

        The KA9Q Internet (TCP/IP) Package: A Progress Report
            Phil Karn KA9Q            6th (1987)

    Amateur TCP/IP: An Update
            Phil Karn KA9Q            7th (1988)

    Amateur TCP/IP in 1989
            Phil Karn KA9Q            8th (1989)

    Services and Protocols

    The Design of a Mail System for the KA9Q Internet protocol
            Bdale Garbee, N3EUA        6th (1987)
            Gerard van der Grinten, PA0GRI

    Finger - A User Information Lookup Service
            Michael T. Horne, KA7AXD       7th (1988)

    Callsign Server for the KA9Q Internet Protocol Package
            Doug Thom, N6OYU        8th (1989)
            Dewayne Hendricks, WA8DZP

    The Network News Transfer Protocol and its Use in Packet Radio
            Anders Klemets, SM0RGV            9th (1990)

    A Routing Agent for TCP/IP: RFC 1058 Implemented for the KA9Q
    Internet Protocol Package            7th (1988)
            Albert G. Broscius, N3FCT

    Thoughts on the Issues of Address Resolution and Routing in
    Amateur Packet Radio TCP/IP Networks
            Bdale Garbee, N3EUA        6th (1987)

    Another Look at Authentication
            Phil Karn KA9Q            6th (1987)

    LZW Compression of Interactive Network Traffic
            Anders Klemets, SM0RGV            10th (1991)

    PACSAT Protocol Suite -- An Overview
            Harold Price, NK6K        9th (1990)
            Jeff Ward, G0/K8KA

    BULLPRO -- A Simple Bulletin Distribution Protocol
            Tom Clark, W3IWI        9th (1990)

    Macintosh

    KA9Q Internet Protocol Package on the Apple Macintosh
            Dewayne Hendricks, WA8DZP       8th (1989)
            Doug Thom, N6OYU

    Status Report on the KA9Q Internet Protocol Package for the
    Apple Macintosh
            Dewayne Hendricks, WA8DZP       9th (1990)
            Doug Thom, N6OYU

    Higher Speed Amateur Packet Radio using the Apple Macintosh
    Computer
            Doug Yuill, VE3OCU        10th (1991)

    Network design

    The Implications of High-Speed RF Networking
            Mike Chepponis, K3MC        8th (1989)
            Glenn Elmore, N6GN
            Bdale Garbee, N3EUA
            Phil Karn, KA9Q
            Kevin Rowett, N6RCE

    Design of a Next-Generation Packet Network
            Bdale Garbee, N3EUA        8th (1989)

    More and Faster Bits: A Look at Packet Radio's Future
            Bdale Garbee, N3EUA        7th (1988)

    Physical Layer Considerations in Building a High Speed Amateur
    Radio Network
            Glenn Elmore, N6GN        9th (1990)

    Spectral Efficiency Considerations for Packet Radio
            Phil Karn, KA9Q            10th (1991)

        This should be considered to be required reading.

    MACA - A New Channel Acess Method for Packet Radio
            Phil Karn, KA9Q            9th (1990)

    A Duplex Packet Radio Repeater Approach to Layer One
    Efficiency
            Robert Finch, N6CXB        6th (1987)
            Scott Avent, N6BGW

    A Duplex Packet Radio Repeater Approach to Layer One
    Efficiency, Part Two
            Scott Avent, N6BGW        7th (1988)
            Robert Finch, N6CXB


    Network Implementation

    Packet Radio at 19.2 kB -- A Progress Report
            John Ackermann, AG9V        11th (1992)

    Implementation of a 1Mbps Packet Data Link
            Glenn Elmore, N6GN        8th (1989)
            Kevin Rowett, N6RCE

    Hubmaster: Cluster-Based Access to High-Speed Netowrks
            Glenn Elmore, N6GN        9th (1990)
            Kevin Rowett, N6RCE
            Ed Satterthwaite, N6PLO

    Recent Hubmaster Networking Progress in Northern California
            Glenn Elmore, N6GN        9th (1990)
            Kevin Rowett, N6RCE

    The 56 kb/s Modem as a Network Building Block: Some Design
    Considerations
                Barry McLarnon, VE3JF        10th (1991)


    Digital Networking with the WA4DSY Modem - Adjacent Channel
    and Co-Channel Frequency Reuse Considerations
                Ian McEachern, VE3PFH        10th (1991)

    A Full-Duplex 56kb/s CSMA/CD Packet Radio Repeater System
            Mike Chepponis, K3MC        10th (1991)
            Lars Karlsson, AA6IW

    A High Performance, Collision-Free Packet Radio Network
            Phil Karn KA9Q            6th (1987)

    Adaptation of the KA9Q TCP/IP Package for Standalone Packet
    Switch Operation
            Bdale Garbee, N3EUA        9th (1990)
            Don Lemley, N4PCR
            Milt Heath

    Hardware

    The KISS TNC: A Simple Host-to-TNC Communications Protocol
            Mike Chepponis, K3MC        6th (1987)
            Phil Karn, KA9Q

    The Ottawa Packet Interface (PI) A Syncrhonous Serial PC
    Interface for Medium Speed Packet Radio
            Dave Perry, VE3IFB        10th (1991)

    HAPN-2: A Digital Multi-Mode Controller fo the IBM PC
            John Vanden Berg, VE3DVV    11th (1992)

    The PackeTen system - The Next Generation Packet Switch
            Don Lemley, N4PCR        9th (1990)
            Milt Heath

----------------------------------------------------------------------